home *** CD-ROM | disk | FTP | other *** search
/ Halting the Hacker - A P…uide to Computer Security / Halting the Hacker - A Practical Guide to Computer Security.iso / rfc / rfc932.txt < prev    next >
Text File  |  1997-04-01  |  9KB  |  227 lines
  1. Network Working Group                                     David D. Clark
  2. Request for Comments: 932                                       MIT, LCS
  3.                                                             January 1985
  4.  
  5.                      A SUBNETWORK ADDRESSING SCHEME
  6.  
  7.  
  8. STATUS OF THIS MEMO
  9.  
  10.    This RFC suggests a proposed protocol for the ARPA-Internet
  11.    community, and requests discussion and suggestions for improvements.
  12.    Distribution of this memo is unlimited.
  13.  
  14. INTRODUCTION
  15.  
  16.    Several recent RFCs have discussed the need for a "subnet" structure
  17.    within the internet addressing scheme, and have proposed strategies
  18.    for "subnetwork" addressing and routing.  In particular, Jeff Mogul
  19.    in his RFC-917, "Internet Subnets", describes an addressing scheme in
  20.    which a variable number of the leading bits of the host portion of
  21.    the address are used to identify the subnet.  The drawback to this
  22.    scheme is that it is necessary to modify the host implementation in
  23.    order to implement it.  While the modification is a simple one, it is
  24.    necessary to retrofit it into all implementations, including those
  25.    which are already in the field. (See RFC-917 by Mogul for various
  26.    alternative approaches to this problem, such as using Address
  27.    Resolution Protocol.)
  28.  
  29.    This RFC proposes an alternative addressing scheme for subnets which,
  30.    in most cases, requires no modification to host software whatsoever.
  31.    The drawbacks of this scheme are that the total number of subnets in
  32.    any one network are limited, and that modification is required to all
  33.    gateways.
  34.  
  35. THE PROPOSAL
  36.  
  37.    In this scheme, the individual subnets of a network are numbered
  38.    using Class C addresses.  Since it is necessary with this scheme that
  39.    a Class C address used to number a subnet be distinguishable from a
  40.    Class C address used to number an isolated network, we will reserve
  41.    for subnetworks the upper half of the Class C address space, in other
  42.    words all those Class C addresses for which the high order bit is on.
  43.    When a network is to be organized as a series of subnetworks, a block
  44.    of these reserved Class C addresses will be assigned to that network,
  45.    specifically a block of 256 addresses having the two first bytes
  46.    identical.  Thus, the various subnetworks of a network are
  47.    distinguished by the third byte of the Internet address.  (This
  48.    addressing scheme implies the limitation that there can only be 256
  49.    subnetworks in a net.  If more networks are required, two blocks will
  50.    have to be allocated, and the total viewed as two separate networks.)
  51.  
  52.  
  53.  
  54. Clark                                                           [Page 1]
  55.  
  56.  
  57.  
  58. RFC 932                                                     January 1985
  59. A Subnetwork Addressing Scheme
  60.  
  61.  
  62.    The gateways and hosts attached to this subnetted network use these
  63.    addresses as ordinary Class C addresses.  Thus, no modification to
  64.    any host software is required for hosts attached to a subnetwork.
  65.  
  66.    For gateways not directly attached to the subnetted network, it is an
  67.    unacceptable burden to separately store the routing information to
  68.    each of the subnets. The goal of any subnet addressing scheme is to
  69.    provide a strategy by which distant gateways can store routing
  70.    information for the network as a whole.  In this scheme, since the
  71.    first two bytes of the address is the same for every subnet in the
  72.    network, those first two bytes can be stored and manipulated as if
  73.    they are a single Class B address by a distant gateway. These
  74.    addresses, which can be used either as a Class B or Class C address
  75.    as appropriate, have been informally called Class "B 1/2" addresses.
  76.  
  77.    In more detail, a gateway would treat Class C addresses as follows
  78.    under the scheme.  First, test to see whether the high order bit of
  79.    the address is on.  If not, the address is an ordinary Class C
  80.    address and should be treated as such.
  81.  
  82.    If the bit is on, this Class C address identifies a subnet of a
  83.    network.  Test to see if this gateway is attached to that network.
  84.    If so, treat the address as an ordinary Class C address.
  85.  
  86.    If the gateway is not attached to the network containing that
  87.    subnetwork, discard the third byte of the Class C address and treat
  88.    the resulting two bytes as a Class B address.  Note that there can be
  89.    no conflict between this two-byte pattern and an ordinary Class B
  90.    address, because the first bits of this address are not those of a
  91.    valid Class B address, but rather those of a Class C address.
  92.  
  93. OPTIMIZATIONS
  94.  
  95.    If a network grows to more than 256 subnetworks, it will be necessary
  96.    to design two distinct blocks of special Class C addresses, and to
  97.    view this aggregate as two separate networks.  However, the gateways
  98.    of these two networks can, by proper design, run a joint routing
  99.    algorithm which maintains optimal routes between the two halves, even
  100.    if they are connected together by a number of gateways.
  101.  
  102.    Indeed, in general it is possible for gateways that are not directly
  103.    attached to a subnetworked network to be specially programmed to
  104.    remember the individual Class C addresses, if doing so provides
  105.    greatly improved network efficiency in some particular case.
  106.  
  107.    It was stated earlier that no modification to the host software is
  108.    necessary to implement this scheme.  There is one case in which a
  109.  
  110.  
  111. Clark                                                           [Page 2]
  112.  
  113.  
  114.  
  115. RFC 932                                                     January 1985
  116. A Subnetwork Addressing Scheme
  117.  
  118.  
  119.    minor modification may prove helpful.  Consider the case of a distant
  120.    host, not immediately attached to this subnetworked network.  That
  121.    host, even though at a distance, will nonetheless maintain separate
  122.    routing entries for each of the distinct subnetwork addresses about
  123.    which it has any knowledge.  For most hosts, storing this information
  124.    for each subnet represents no problem, because most implementations
  125.    do not try to remember routing information about every network
  126.    address in the Internet, but only those addresses that are of current
  127.    interest.  If, however, for some reason the host has a table which
  128.    attempts to remember routing information about every Internet address
  129.    it has ever seen, than that host should be programmed to understand
  130.    the gateway's algorithm for collapsing the addresses of distant
  131.    subnets from three bytes to two.  However, it is not a recommended
  132.    implementation strategy for the host to maintain this degree of
  133.    routing information, so under normal circumstances, the host need not
  134.    be concerned with the C to B conversion.
  135.  
  136. DRAWBACK
  137.  
  138.    The major drawback of this scheme is that any implementation storing
  139.    large tables of addresses must be changed to know the "B 1/2"
  140.    conversion rule. Most importantly, all gateways must be programmed to
  141.    know this rule.  Thus, adoption of this scheme will require a
  142.    scheduled mandatory change by every gateway implementation.  The
  143.    difficulty of organizing this is unknown.
  144.  
  145. OTHER VARIATIONS
  146.  
  147.    It is possible to imagine other variations on the patterns of
  148.    collapsing addresses.  For example, 256 Class B addresses could be
  149.    gathered together and collapsed into one Class A address.  However,
  150.    since the first three bits of the resulting Class A address would be
  151.    constrained, this would permit only 32 such subnetted networks to
  152.    exist.  A more interesting alternative would be to permit the
  153.    collapse of Class C addresses into a single Class A address.  It is
  154.    not entirely obvious the best way of organizing the sub-fields of
  155.    this address, but this combination would permit a few very large nets
  156.    of subnets to be assembled within the Internet.
  157.  
  158.    The most interesting variation of "B 1/2" addresses is to increase
  159.    the number of bits used to identify the subnet by taking bits from
  160.    the resulting Class B address.  For example, if 10 bits were used to
  161.    identify the subnet (providing 1024 subnets per network), then the
  162.    gateway, when forming the equivalent address, would not only drop the
  163.    third byte but also mask the last two bits of the B address.  Since
  164.    the first three bits of the address are constrained, this would leave
  165.    13 bits for the network number, or 8192 possible subnetworked
  166.  
  167.  
  168. Clark                                                           [Page 3]
  169.  
  170.  
  171.  
  172. RFC 932                                                     January 1985
  173. A Subnetwork Addressing Scheme
  174.  
  175.  
  176.    networks.  This number is not as large as would be desirable, so it
  177.    is clear that selecting the size of the subnet field is an important
  178.    compromise.
  179.  
  180.    Danny Cohen has suggested that this scheme should be fully
  181.    generalized so that the boundaries between the network, subnetwork,
  182.    and host field be arbitrarily movable.  The problem in such a
  183.    generalization is to determine how the gateway is to maintain the
  184.    table or algorithm which permits the collapsing of the address to
  185.    occur.  This RFC proposes that, in the short run, only one single
  186.    form of "B 1/2" addresses be implemented as an Internet subnet
  187.    standard.
  188.  
  189.  
  190.  
  191.  
  192.  
  193.  
  194.  
  195.  
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202.  
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225. Clark                                                           [Page 4]
  226.  
  227.